(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(1 9) World Intellectual Property Organization 

International Bureau 



lllllllllllllllllllllllllllllllllllllllllllllllllllllllll 



(43) International Publication Date 
9 August 2001 (09.08.2001) 



PCT 



(10) International Publication Number 

WO 01/57613 A2 



(51) International Patent Classification 7 : G06F 

(21) International Application Number: PCT/USO 1/03087 

(22) International Filing Date: 31 January 2001 (31.01.2001) 

(25) Filing Language: English 

(26) Publication Language: English 

(30) Priority Data: 

09/496,361 1 February 2000 (01.02.2000) US 

(71) Applicant: VENTRO CORPORATION [US/US]; 1500 
Plymouth Street, Mountain View, CA 94043 (US). 

(72) Inventors: MACKAY, Robert, R.; 403 East Cattail Court, 
j Saratoga Springs. UT 84043 (US). TRUJILLO, Kristo- 
■ pher, O.; 576 North 2310 West, Provo, UT 84601 (US). 
I BLOYER, Donald, R.; 1054 Lincoln Lane, Park City, UT 
| 84098 (US). BERTOLA, Benjamin, K.; 2085 Pinnacle 
| Terrace Way #306, Salt Lake City, UT 84 1 2 1 (US). 



(81) Designated States (national): AE, AG, AL, AM, AT, AU, 

AZ, BA, BB, BG, BR, BY, BZ, CA, CH, CN, CR, CU, CZ, 
DE, DK, DM, DZ, EE, ES, FI, GB, GD, GE, GH, GM, HR, 
HU, ID, IL, IN, IS, JP, KE, KG, KP, KR, KZ, LC, LK, LR, 
LS, IT, LU, LV, MA, MD, MG, MK, MN, MW, MX, MZ, 
NO, NZ, PL, PT, RO, RU, SD, SE, SG, SI, SK, SL, TJ, TM, 
TR, TT, TZ, UA, UG, UZ, VN, YU, ZA, ZW. 

(84) Designated States (regional): ARIPO patent (GH, GM, 
KE, LS, MW, MZ, SD, SL, SZ, TZ, UG, ZW), Eurasian 
patent (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), European 
patent (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, 
IT, LU, MC, NL, PT, SE, TR), OAPI patent (BF, BJ, CF, 
CG, CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG). 

Published: 

— without international search report and to be republished 
upon receipt of that report 

For two-letter codes and other abbreviations, refer to the "Guid- 
ance Notes on Codes and Abbreviations " appearing at the begin- 
ning of each regular issue of the PCT Gazette. 



\ (74) Agent: OGILVIE, John, W., L.; Computer Law++, 121 1 
j East Yale Avenue, Salt Lake City, UT 84105 (US). 



j (54) Title: HUB AND SPOKE ARCHITECTURE AND METHODS FOR ELECTRONIC COMMERCE 





COMMUNICATION 112 




ELECTRONIC 
COMMERCE 


TRANSMISSION 
ERROR 


AUTHENTICATION 306 | 








SIGNAL 300 


HANDLING 304 


| NETWORK ADDRESSING 302 









< 



(57) Abstract: The present invention provides tools and techniques for electronic commerce. In a hub and spoke architecture (100), 

. communications (1 12) are exchanged using XML or another self-documenting format. The communications include electronic com- 

^ merce transaction data (400) such as purchase order data. Communications may include processing instructions (406) which refer 
to additional instructions stored at the hub (1 10). Communications may include a substantially complete history (408) of the trans- 
action's life thus far within the architecture. The invention does not require that each client (102) know detailed information about 
^ each other client for commercial communications to be routed. For instance, the hub may select vendors in cases where the client 
^ placing a purchase order has specified items and item counts but has not expressly specified or limited the choice of vendor. 
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HUB & SPOKE ARCHITECTURE AND METHODS 
FOR ELECTRONIC COMMERCE 

FIELD OF THE INVENTION 

5 The present invention relates generally to electronic commerce, and relates more 

particularly to tools and techniques for using a central service provider to perform business 
transactions between other entities by transmitting transaction data between the entities in a 
shared self-documenting format. 

10 TECHNICAL BACKGROUND OF THE INVENTION 

Electronic commerce could be defined very generally, so that it includes any 
exchange of business and/or financial information involving any analog and/or digital 
electronic device. However, the electronic commerce of interest here involves digital 
computers which are connected by one or more computer networks. Moreover, we are 

15 concerned with electronic communications that are directed mainly at commerce between 
businesses, rather than commerce between individual consumers and a business. 

For instance, some businesses use electronic data interchange ("EDI") tools or 
techniques to exchange commercial information and perform business transactions. Examples 
of EDI and its uses may be found in United States Patent No. 5,202,977 issued to Pasetes, Jr. 

20 et al. ("Pasetes"), United States Patent No. 5,557,780 issued to Edwards et al., United States 
Patent No. 5,812,669 issued to Jenkins et al. ("Jenkins"), United States Patent No. 5,878,419 
issued to Carter, and other public documents. EDI is generally used in the context of a direct 
physical data transmission connection between two trading partners, as discussed in Pasetes, 
but Jenkins states that EDI can also be used securely over an open network such as the 

25 Internet. 

While EDI can provide speed and reliability advantages over corresponding 
exchanges of paper, EDI also has significant disadvantages as presently used. For instance, 
EDI documents are written in a complex language agreed upon by their sender and recipient. 
As a result, numerous cross-references and the need to perform lookup operations complicate 
30 the use of EDI, and so does the need for all parties to agree on and implement the specific 
EDI format to be used in a particular transaction. Dozens or even hundreds of individual EDI 
formats may be defined for use by a given pair of trading partners. 

In response to the cost, complexity, and other disadvantages of relying primarily on 
EDI for business-to-business commerce, alternatives are emerging. Some alternatives 
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combine EDI with use of an extensible markup language ("XML"). Unlike EDI, XML is self- 
documenting in that XML allows users to define information about data structures and 
content inside an XML document, in a standard way. Because XML has roots in the world 
wide web's HyperText Transfer Protocol ("HTTP") and Standard Generalized Markup 
5 Language ("SGML"), some in the industry believe that XML is also better suited than EDI 
for standard use on the Internet. XML, EDI, and electronic commerce are discussed further, 
for instance, in a Harbinger Corporation white paper entitled "extensible Markup Language" 
available through the web site www.harbinger.com. The Harbinger white paper, the patents 
identified above, and other references are also being filed by applicants with the U.S. Patent 

10 and Trademark Office to be made of record in this application. 

In short, a wide variety of approaches are being proposed and/or used to facilitate 
business-to-business electronic commerce. In some cases, the relative strengths and 
weaknesses of the approaches are well understood; in other cases, firm conclusions are 
harder to reach. In this type of dynamic environment, which is filled with both risk and 

15 promise, it would be an advancement in the art to provide new tools and techniques for 

facilitating electronic commerce. It would be a further advance to do so without abandoning 
in every instance the older components of such commerce, such as EDI and the so-called 
"legacy systems" used within a given business entity. Accordingly, new tools and techniques 
which increase the choices available for performing electronic commerce are disclosed and 

20 claimed herein. 

BRIEF SUMMARY OF THE INVENTION 

The present invention provides tools and techniques for electronic commerce. In 
particular, some embodiments of the invention include a hub & spoke architecture for 

25 integrating disparate systems into transaction communities with migrating encapsulated 
process information. The architecture is a hub & spoke architecture (alternately denoted a 
"hub-and-spoke" or "hub and spoke" architecture) in that one or more servers at one or more 
logically central locations service client programs at various client business entities; the 
server is at the hub, and the client entities define outlying spokes extending from the hub. The 

30 logically central location is central in the network topology sense; it is not necessarily 

physically or geographically central. This hub & spoke topology is in contrast with a peer-to- 
peer topology, for instance, in which clients would communicate directly with each other 
instead of going through a central location. 
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The hub is als.o central in a business role sense, because transactions between clients 
are assisted by the hub. For instance, the hub monitors activity to identify purchase orders 
that have been sent but not filled, and takes follow-up action accordingly. In some 
embodiments, the hub includes procurement software which chooses the supplier(s) best 
5 suited for filling a given purchase order. That is, the buyer need not specify particular 
suppliers, although that can be done; it is enough to specify the desired items and their 
respective quantities. As a result of these hub capabilities, the hub is more than a mere 
conduit for data. The hub does provide data transmission or networking services, but the hub 
is also an active provider of electronic commerce services such as transaction monitoring and 

10 procurement management services. 

The various client entities may use different electronic commerce programs internally. 
For example, one client entity might use a particular set of EDI formats, while another client 
entity uses a different set of EDI formats, a third entity uses custom procurement software 
and a relational database, and a fourth entity uses a combination of spreadsheets and paper 

15 forms. The inventive clients can translate these and other disparate commercial documents 
into a shared self-documenting format which is used in the transmissions between the hub 
server and the clients involved in a given transaction. Thus, the invention integrates disparate 
client entities into a community for the duration of the transaction in question. 

Unlike approaches that maintain log files at the network nodes in an electronic 

20 commerce network, the present invention maintains migrating encapsulated process 

information. That is, the hub server and clients maintain within the transmissions for a given 
transaction a substantially complete history of that transaction. This allows the hub and the 
clients to detect, diagnose, and at least attempt to overcome problems that may arise, without 
requiring synchronization or replication of logs. Separate logs may also be used, but they are 

25 not required, because the log is maintained in the transmissions for the transaction. 

A complete history of the steps taken to complete the transaction qualifies as a 
substantially complete history, but an entirely complete history is not always required. Data 
and/or events may be omitted from the history if they are not needed to address unacceptable 
delays, lost transmissions, scrambled transmissions, payment refusal, or other electronic 

30 commerce problems. Thus, the invention only requires a history which is "substantially" 

complete, not one that contains every detail of every event involving the transaction at hand. 

In addition to an architecture for electronic commerce, the invention provides 
electronic commerce signals, methods, and configured storage media. In each case, the 
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invention provides new tools and techniques for facilitating electronic commerce without 
necessarily abandoning use of EDI, enterprise resource planning software, other procurement 
software, spreadsheets, relational databases, and so on within the client entities. XML, 
commercial XML, or another self-documenting language is used for communications 
5 between clients and the hub. Familiar tools for encryption, remote software updates, and data 
transmission in a network are readily adapted for use according to the present invention. 
Other features and advantages of the present invention will become more fully apparent 
through the following description. 

10 BRIEF DESCRIPTION OF THE DRAWINGS 

To illustrate the manner in which the advantages and features of the invention are 
obtained, a more particular description of the invention will be given with reference to the 
attached drawings. These drawings only illustrate selected aspects of the invention and thus 
do not limit the invention's scope. In the drawings: 
15 Figure 1 is a diagram illustrating a hub & spoke architecture for electronic commerce 

according to the present invention. 

Figure 2 is a diagram further illustrating a client according to the present invention, 
with reference to the clients shown in Figure 1. 

Figure 3 is a diagram further illustrating an electronic commerce communication 
20 according to the present invention, with reference to the communications shown in Figure 1 . 

Figure 4 is a diagram further illustrating an electronic commerce signal of the present 
invention, from a communication of the kind shown in Figures 1 and 3. 

Figure 5 is a diagram further illustrating data flow during an example use of the hub 
& spoke architecture shown in Figure 1. 
25 Figure 6 is a flow chart further illustrating methods of the present invention. 

Figure 7 is a diagram illustrating a hub & spoke architecture for electronic commerce 
in use by a hospital according to the present invention. 

Figure 8 is a diagram further illustrating data processing in a client according to the 
present invention. 

30 Figure 9 is a diagram further illustrating steps and structures in a client according to 

the present invention. 

Figure 1 0 is a flow chart further illustrating processing at the hub according to the 
present invention. 

4 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

The present invention provides business tools and techniques for facilitating 
electronic commerce. The invention may be embodied in various ways, and it may also be 
5 described in various ways. Accordingly, the examples discussed throughout this document 
are not necessarily consistent with one another in every particular; rather than omitting details 
to achieve complete consistency, details are included if they may assist in a better 
understanding of an embodiment of the invention. 

10 Overview 

The invention provides a network-based design for electronic commerce, namely, a 
design having novel features at a transactional level. In other words, the invention provides a 
commerce network built on top of one or more otherwise conventional computer networks. A 
"transaction" in the commerce network is viewed as a business transaction, as opposed to a 

15 mere exchange of data packets or some other network operation at the network physical level. 
Client entities who participate in electronic commerce using the commerce network do not 
require specific computer networking knowledge of each other. For instance, they do not 
need to know the other participant's computer system information, IP or other network 
delivery addresses, physical location, or any other data needed to transmit communications 

20 electronically; these details are handled by the hub server and the commerce client software. 
The invention utilizes conventional computer networking technology with novel 
additional tools and techniques in order to let client entities execute business transactions in 
an electronic form. For instance, the invention permits use of virtually any available network 
communication protocol(s), such as Ethernet, SLIP, Token-Ring, TCP, and so on. Likewise, 

25 the invention permits use of virtually any available network transport mechanism(s), such as 
HTTP, SMTP, FTP, and so on. 

One system according to the invention is capable of translating commercial data 
between the data formats that are used by client entities and a common transactional language 
format that is shared by all clients in the commerce network. The invention transports 

30 business data from one client entity to another client entity through a central hub that is 
operated by an electronic commerce service provider. Each client entity has a separately 
installed client software program (called the "client") for communications with the central 
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hub. This defines a hub & spoke topology for the commerce network; the underlying 
computer networks may have ring, web, hub & spoke, or one or more other topologies. 

By contrast with many EDI systems or another direct connection approach, which 
require specific physical interconnections between client entities, the commerce network is 
5 created without such specific physical interconnections because it uses Internet or world wide 
web networks. Some current EDI systems also use the Internet for data exchange. Even in 
such cases, however, it is necessary for one peer to directly identify the other peer with whom 
data will be exchanged. 

By contrast, embodiments of the present invention use the central hub to connect the 

10 entities. In particular, a buyer entity may place an order without directly identifying the seller. 
The hub will select one or more seller(s) to fill the order after reviewing the purchase order to 
identify desired items, accessing catalogs, price lists, and other familiar components, and 
checking lists or other structures that identify sellers in the hub & spoke architecture. Thus, 
the buyer does not need to specify in each instance the address of the target vendor entity. 

15 The communications across a variety of client entity platforms is standardized within 

the hub & spoke architecture by use of a self-describing data structure, such as one 
implemented with XML. A given inventive communication transmitted between client and 
* hub typically contains business information, electronic commerce routing instructions (as 
opposed to computer network router or bridge instructions), and electronic commerce 

20 processing instructions (such as who should be notified at the client entity when the 
communication arrives). Suitable business information includes data for an electronic 
commerce transaction, such as purchase order data, invoice data, catalog data, and so on. By 
using XML, this data can be easily described in the communication, unlike similar data in 
EDI exchanges, for instance. The descriptions of transaction data are preferably set forth in a 

25 consistent fashion by using a single internal (hub-client) format. This is different from 

electronic commerce systems in which XML is used to implement a variety of definitions for 
compatibility with still other systems, thereby increasing the system complexity and making 
it more difficult to maintain and support. 

Another notable feature of the present communications is that they typically each 

30 contain a substantially complete transaction history. The history is located in the same self- 
describing structure, and plays a significant role in supporting the electronic commerce 
infrastructure. For instance, the history supports transaction management in the loosely 
coupled commerce network. Proactive management of transactions is important to the 
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ongoing success and performance of an inventive system, as are somewhat similar steps in 
other connected disparate entities. For instance, in a computer network routers and switches 
will support recasting or rebroadcasting of packets that are unconfirmed. This is an 
immediate response to failure. In the inventive commerce network, retransmissions may also 
5 be called for, but there is normally a longer delay between action and reaction than there is at 
the network packet level. 

Transaction lifecycle and the steps involved in executing a transaction are tied directly 
to the document data by means of the embedded transaction history, which is carried with the 
document at each of the various points of system interaction. Through this method of local 

10 history support, any commercial document in the system can be tracked, and problems can be 
resolved without centralized administration. 

For instance, assume the problem is a failed purchase order acknowledgment. That is, 
the hub expected to receive from a vendor client an acknowledgment of a purchase order 
communication forwarded to the vendor client by the hub from a buyer client. The 

15 transaction failure is discovered and identified by reviewing the history in the transaction and 
measuring the amount of time since the last history event. Measurement may use rules 
embedded in the communication to determine if the elapsed time is too long. Other embedded 
rules cause the hub to send a request for response and/or to notify a particular person of the 
problem by email or pager. 

20 Without the invention, it might be necessary to contact the buyer client to determine 

the time the order was placed by their system, contact their account manager to determine the 
acceptable delay, calculate the delta between these times, compare it to the elapsed time, and 
then contact the buyer client again to ask that a confirmation of the order be sent. This 
example treats a very simple problem. As problem complexity escalates, so does the level of 

25 effort required to resolve the problem, and the corresponding benefits of automation with the 
invention. 

The novel system has been designed to allow abstraction from the delivery type (e.g., 
file transfer, message transfer, database transfer, electronic mail transfer), the transaction data 
(e.g., purchase order, catalog), and the delivery mechanism (e.g., FTP for files, JMS for 
30 messages) used in a particular instance. The invention can be used in virtually any computing 
environment currently in production, as long as that environment includes at least a Java 
Virtual Machine or its approximate equivalent, and a network connection of some form. 
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Encryption in the inventive system may be based on a variety of solutions. Encryption 
is often related to the transport type, since differing transportation types use differing 
mechanisms for security. Transaction data may also be encrypted by the client independently 
of and in addition to any encryption performed by the delivery mechanism. 
5 The user interface for the system is based upon a centralized website that provides 

support for various system functions, such as: configuration capabilities, including setting the 
network addresses for delivery, notification, monitoring and reporting; output mapping and 
translation instructions; delivery notification; receipt confirmation; software upgrades to 
clients; and data requests requiring selection and incremental delivery of catalog data, for 

10 example. The centralized web site (also referred to as the "hub" or "hub server") thus supports 
the remote client installations. In some embodiments, the hub can reproduce the client 
installation exactly after a total client loss at the remote system. 

The centralized site also provides customization capabilities for the output formats 
provided by the client in the form of mappings that allow an XML programmer, for instance, 

15 to implement translations between specific client entity formats and the shared self- 
documenting format of the hub-client communications. The mappings are embedded in the 
communications, so they are generally available with each delivery of a transaction to a 
remote client. The resulting flexibility allows for a dynamic change to an output format from 
a centralized location that is then executed with the next transactional delivery. The change in 

20 mappings between two transactions does not cause either transaction to fail. 

The central site also allows for synchronized software module addition, whereby each 
client is kept in sync with the server and each other client that is also using a given module. 
For instance, a remote client or the hub may add a new format adapter. An adapter addition at 
the client generates a communication that includes the added module, the configuration file, 

25 and contact information that is delivered to the server and posted as a client change. 

Similarly, the server may post a client change to the configuration at the server, which would 
then be reflected to the client to be decrypted if necessary, decompressed if necessary, 
otherwise extracted from the communication, and installed at the client entity. 

Accordingly, embodiments of the invention may include a transaction processing 

30 monitor ("TPM") at the hub which supports a loosely coupled network of remote nodes 
(clients) for the purpose of commercial data exchange. Clients do not necessarily perform 
transaction processing monitoring, although the system does support internal transactional 
integrity. Although the inventive system enforces transactional integrity through the 



WO 01/57613 



PCT7US01/03087 



confirmation of delivery of a given step in a transaction, it is an EDI/asynchronous-style 
enforcement process, not a TPM-style transaction. Some embodiments provide rollback 
capabilities at the client as well as the hub. In a sense, the invention thus combines the high- 
response transactional model of a TPM with the loosely-coupled transactional model of EDI. 
5 It may also be stated that, rather than being request based system, the inventive 

system is a workflow driven, event driven system in which the server and client each push 
data without a request to each other. In other words, a request model need not be involved. 
The only time a response is generated is to confirm the receipt of the push. 

10 Architecture 

Figure 1 illustrates a hub & spoke architecture according to the present invention, 
indicated generally at 100. The architecture 100 facilitates electronic commerce between 
client entities 102 by providing services managed by a service provider 104. Electronic 
commerce may also be performed between a client entity 102 and the service provider 104 

1 5 using the architecture 100. 

Each client entity 102 will have some type of transaction system 106. The systems 
106 may be installed in connection with the corresponding client entity's subscription to the 
service provider 104 services, but most systems 106 will already be present when the client 
108 is installed. Likewise, a given system 106 will generally be used only internally within a 

20 particular client entity 1 02, but in some cases the system 1 06 may be outsourced and/or 

located at a data center leased by the client entity 102. To distinguish these systems 106 from 
the other elements shown, the systems 106 are termed "single-entity" systems; they are 
sometimes referred to elsewhere as "legacy systems". Unlike client software and/or hardware 
108, and unlike hub server software and/or hardware 110, the systems 106 do not normally 

25 link trading partners to allow communications 1 12 as taught herein. However, the fact that a 
system 106 may support EDI or another conventional electronic commerce capability does 
not prevent it from being a "single-entity" system with respect to the present invention. 

Clients 108 are novel elements of the present invention, provided specifically to 
support communications within the hub & spoke architecture 100. Clients 108 may be 

30 implemented in some embodiments as software installed on general-purpose computer 

hardware, and in other embodiments may include special-purpose hardware according to the 
present invention. The line between hardware and software becomes increasingly indistinct as 
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tools like application-specific integrated circuits ("ASICs"), field programmable gate arrays 
("FPGAs"), and so on become more widely available. 

In operation, clients 108 perform as discussed in the Overview and Development 
History sections, and elsewhere herein. For instance, in one embodiment a client 108 at a 
5 buyer entity receives purchase order data from the single-entity transaction system 1 06, 

translates it from the system 106 format (e.g., EDI) into a self-documenting format such as an 
XML format, creates a communication 1 12 containing the data and related information such 
as the history of the transaction thus far, and sends the communication to the hub server 1 10. 
A client 108 at a vendor entity receives the XML data, extracts the purchase order data, 

10 optionally sends the hub server an acknowledgement confirming receipt of the purchase order 
communication 1 12, converts from XML to the client entity system 106 format, and submits 
the purchase order data in that format to the vendor's system 106. Clients operate similarly 
with regard to invoices, catalog request and fulfillment, and other commercial transactions. 
Communications 1 12 are discussed further in connection with Figures 3 and 4, and elsewhere 

15 herein. 

A client 108 may exchange data with the local single-entity transaction system 106 by 
way of a buffer 1 14 using a post-and-subscribe approach, semaphores, signals, or other 
familiar inter-process communication tools and techniques. The buffer 1 14 includes volatile 
memory such as RAM and/or non- volatile memory such as a magnetic hard disk. Clients 108 

20 and their interfaces with the systems 1 06 and the hub server 1 1 0 are discussed further 
elsewhere herein, such as in connection with Figure 2. 

In its various embodiments, the hub server 1 10 generally supports asynchronous 
message storage and retrieval, through message queues or similar mechanism. Suitable 
implementations may use, for instance, IBM MQSeries software, TIB/Rendezvous software, 

25 Weblogic App Server software, or other message-based middleware and/or Java application 
server software in a messaging and information infrastructure. 

Like the clients 108, the server 110 includes code that understands the format of 
communications 1 12 to embed or extract transaction data, provides network routing, and 
provides confirmation upon receipt of a message 112. Extendable delivery mechanisms 

30 provide for actual transmission of the message 112 through the network "wire". These work 
with a routing system that contains client 102 addresses, and a centralized store containing all 
the configuration details, such as which transport adapters are installed at which clients. 
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The hub 110 preferably also includes exception handling capability as part of the 
transaction management logic. When expected messages 1 12 do not arrive, the server 110 
takes appropriate steps. For instance, a notification system ties exception handling and 
transaction management together and provides email or other notification to designated 
5 persons at the involved entities 102, 104. 

In some embodiments, the service provider 104 also provides procurement accounting 
hardware and/or software 1 16, such as enterprise resource planning ("ERP") software, 
inventory databases and database managers, and other conventional procurement 
management tools. The procurement module 116 exchanges data with the hub server 110. 
10 When present, the procurement software 1 1 6 provides the hub server with access to business 
logic, possibly including access to internal systems of the service provider 104 which are not 
directly available to other systems in the environment 100. For instance, the procurement 
software 1 16 may identify the best supplier for a given set of items in a purchase order. The 
procurement software 116 may include and/or access accounting data, transactional data, 
15 reporting information, product information, access control information, credit status, and 
other business data as deemed necessary to support the hub 110 and the commercial 
transactions requested by clients 108. 

Like the other Figures and examples given herein, Figure 1 is illustrative only. In 
various embodiments of the invention, components shown in Figure 1 may be omitted, 
20 repeated, renamed, or grouped differently. For instance, the leftmost client entity 102 in 
Figure 1 includes a firewall 118 between the client 108 and the external network, including 
the hub server 110. Other client entities 102 do not necessarily have a firewall, as illustrated 
by the rightmost upper client entity 102 in Figure 1. In some embodiments all client entities 
102 have firewalls, in some none have firewalls, and in some embodiments a client 108 
25 resides outside the firewall rather than inside it. Similarly, Figure 1 shows three client entities 
102, but other embodiments may have more or fewer client entities 102. As noted earlier, 
some embodiments also omit the procurement accounting module 116. 

Clients 

30 Figure 2 illustrates components of a client 108. As noted, the client 108 may be 

implemented as software which configures a general-purpose computer according to the 
invention, or it may be implemented with special-purpose hardware such as ASICs or 
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FPGAs. The client 108 may be a virtual user of the systems 106, in that the client 108 (which 
is a mechanism rather than a person) exchanges data with the systems 1 06. 

The illustrated client 108 includes an incoming data processor 200, an outgoing data 
processor 202, one or more format adapters 204, and one or more transport adapters 206. As 
5 noted in the Development History section, other implementations of the client lack pluggable 
adapters 204, 206, using "hard-coded" format conversion routines and/or hard-coded 
transport protocols instead. Either way, the client 108 uses one or more "mappings" to 
perform format conversion(s). The mappings can be written by any programmer familiar with 
XML and/or XML Style Language ("XSL"). Some embodiments of the invention embed 
10 XSL in the XML file, which is somewhat unusual in the world of XML uses. 

The incoming data processor 200 checks for incoming communications 112 from the 
hub server 110 using at least standard computer networking tools and techniques. The 
transport adapter 206 or other transport mechanism may be viewed as part of the incoming 
data processor 200; as with Figure 1, components of Figure 2 may be grouped differently in 
15 different embodiments of the invention. After receiving a communication 1 12, the incoming 
data processor 200 extracts electronic commerce transaction data from the communication 
1 12, and posts the data to the single-entity -transaction-system 106. The data extraction may 
be defined to include format conversion from XML to the local system 106 format; once 
again, we see that embodiments may group illustrated components differently without 
20 thereby removing them from the scope of the invention. Posting the data may be performed 
by copying it to the buffer 1 14, and setting a flag or otherwise ensuring that the system 106 
will recognize that new data has been posted for the system 106 to process. 

Suitable format adapters 204 include adapters between the client-hub communication 
1 12 self-documenting format and the format used by a single-entity -transaction-system 106. 
25 Familiar component plug-in techniques, including techniques from Java, object-oriented 
programs, COM, or other sources, may be used to include or exclude particular adapters. 
Conversion between XML and legacy system 106 formats may be performed using familiar 
parsing techniques. 

Suitable transport adapters 206 include adapters that provide connectivity using 
30 familiar protocols, such as HTTP, FTP, ARCNET, Ethernet, Token ring, and so on. Some 
type of support for Transport Control Protocol ("TCP") connectivity is preferred. Naturally, 
the hub server 110 includes corresponding transport support for each client 108 in the 
architecture 100. 
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The outgoing data processor 202 operates in a manner that is generally similar to that 
of the incoming data processor 200. The outgoing data processor 202 checks for outgoing 
electronic commerce transaction data from the single-entity-transaction-system 106 by 
receiving an interrupt, polling the buffer 1 14, or another familiar method. The outgoing data 
5 processor 202 embeds at least part of the electronic commerce transaction data (some data 
may be strictly for internal client entity 102 use) in a communication 1 12 in a self- 
documenting format, and sends the communication 1 12 to the hub server 110. The format 
adapter(s) 204 are thus either part of, or used by, the outgoing data processor 202, depending 
on whether a given embodiment regroups the illustrated components, or does not regroup, 
10 respectively. Likewise, the transport adapter(s) 206 may be viewed as being either part of, or 
simply used by, the outgoing data processor 202. 

Communications 

Figure 3 illustrates a communication 1 12 in greater detail. A business transaction 

15 performed with the invention includes one or more communications 112 between hub server 
110 and client(s) 108. A communication in turn includes at least a novel electronic commerce 
signal 300, and conventional computer networking data 302 such as IP addresses and/or 
Uniform Resource Locators ("URLs"). As discussed in connection with Figure 4 and 
elsewhere herein, the electronic commerce signal 300 includes transaction data such as a 

20 purchase order, as well as a history of the transaction thus far, and possible other components. 
A communication 1 12 is independent of the transport protocol used, and need not 
specify how it should be transported. However, a communication 1 12 on the "wire" may 
include checksums, error detection codes, error correction codes, and/or other familial- means 
for transmission error handling 304. Such components 304 may be present in the electronic 

25 commerce signal 300 and pertain only to the contents of that signal 300, or they may be 
calculated using different or additional components of the communication 1 12. As with the 
other Figures, illustrated components of Figure 3 may be omitted, renamed, repeated, or 
grouped differently in different embodiments of the invention. 

A communication 1 12 may include digital signatures, tokens, certificates, private or 

30 public keys, or other familiar means for authentication 306. Again, a given instance of the 
communication 1 12 may include authentication component(s) 306 inside the electronic 
commerce signal 300, outside that signal 300 but within the communication 1 12, or both. 
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Communications 112 and electronic commerce signals 300 may be embodied 
according to the invention in twisted pair, coaxial, or optical fiber cables, telephone lines, 
satellites, microwave relays, modulated AC power lines, and/or other data transmission 
"wires" of the underlying computer network. Communications 1 12 and electronic commerce 
signals 300 may also be embodied in computer memory in the architecture 100, including 
volatile memory such as RAM and non-volatile memory such as a hard disk. 

Communications 1 12 and/or electronic commerce signals 300 may be encrypted (and, 
of course, decrypted) and/or compressed (and decompressed) using familiar tools and 
techniques. In particular, communication 1 12 encryption may be performed by a client 108 
regardless of whether the underlying transport mechanism for transmitting packets to the hub 
1 10 also performs encryption. 

The following example is provided to further understanding of the communications 
1 1 2 and the present invention: 

TRANSACTION docType="832" customerID="999999" origSysRef="283727343"> 

<DELIVERY_METHOD id="21" name="JMS Delivery Method" code="JMS" 
description="This delivers by JMS" 
jndihomename="promedix . ia . TestAdapterHome"> 

< jmsTopicName>promedix . test . TestingTopic</ jmsTopicName> 
<jmsTopicURL>t3: //peach. promedix. com: 7002</jmsTopicURL> 
</DELIVERY_METHOD> 
<CLIENT_DOCUMENT docType="832 "> 
<ADAPTERS> 

<ADAPTER classname="com. promedix. adapter s .XSLAdapter" 
selector="850" regexp=" . *order . * ! . *850\.$"> 
<ADAPTER_STYLESHEET> 

<xsl : stylesheet version="l . 0" 
xmlns : xsl="http: //www. w3 . org/1 999/XSL/Transf orm"> 

<xsl : template match="CatalogRequest"> 
<html> 

<body bgcolor="#ffffff "> 
<center> 

<hl>Catalog created on <xsl : value-of 

select="@RequestDateTime "/> 

</hl> 
<P> 

<font size="+l">Grouped by 

<xsl : value-of select="@GroupedBy"/x/f ont> 
</p> 
<P> . 

<table border="l"> 
<tr> 

<td bgcolor="#7fffd4"Xb>Supplier 

ID</bx/td> 

<td bgcolor="#7fffd4"xb>Sku 

ID</bx/td> 

<td 

bgcolor="#7fffd4 "><b>Name</bx/td> 

<td bgcolor="#7fffd4"Xb>Unit of 

Measure</bx/td> 
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<td bgcolor="#7fffd4"><b>Mfg Part 

Number</bx/td> 

<td bgcolor="#7fffd4"xb>List 

Price</bx/td> 

</tr> 

<xsl:apply-templates select="Product" /> 

</table> 

</p> 

</center> 
</body> 
</html> 
</xsl : template> 

<xsl: template match="Product"> 
<tr> 

<tdxxsl : value-of 



select="@SupplierID"/x/td> 
select="@SkuID"/x/td> 
select="@Name"/x/td> 
select="@UnitOf Measure '7></td> 



■ <td><xsl: value-of 
<tdXxsl : value-of 
<tdxxsl : value-of 
<tdxxsl : value-of 



select="@MfgPartNumber'7x/td> 
25 <td>$<xsl: value-of 

select="@ListPrice"/x/td> 

</tr> 
</xsl:template> 
</xsl : stylesheet> 
30 </ADAPTER_STYLESHEET> 
</ADAPTER> 
</ADAPTERS> 
</CLIENT_DOCUMENT> 
< TRAN S ACT I ON_DOCUMENT > 
35 <CatalogRequest GroupedBy= "Supplier" RequestDateTime="Mon Jan 

10 10:07:34 MST 2000"> 

<Product MfgPartNumber="stuf f 12" Supplier I D="promedix" 
ListPrice="20.25" UnitOfMeasure="ea" Name="stuf f 12" SkuID="stuf f 12"/> 
<Product MfgPartNumber="test3" SupplierID="promedix" 
40 ListPrice="0.1" UnitOfMeasure="ea" Name="test3" SkuID="test3"/> 

<Product MfgPartNumber="stuf f 14" Suppli erID="promedix" 
ListPrice="20. 0" DnitOfMeasure="ea" Name="stuf f 14 " SkuID="stuf f 14 "/> 

<Product MfgPartNumber="stuf f 15" SupplierID="promedix" 
ListPrice="99. 99" DnitOfMeasure="ea" Name="stuf f 15" SkuID="stuf f 15"/> 
45 <Product Mf gPartNumber="stuf f 16" SupplierID="promedix" 

ListPrice="2.25" OnitOfMeasure="ea" Name="stuf f 16" SkuID="stuf f 16'7> 

<Product MfgPartNumber="testllll" SupplierID="promedix" 
ListPrice="19. 99" QnitOfMeasure="cs" Name="test" SkuID="testy"/> 

<Product MfgPartNumber="promedixlll" SupplierID="promedix" 
50 ListPrice="19.99" UnitOfMeasure="cs" Name="product for promedix.com" 
SkuID="promedixlll"/> 

</CatalogRequest> 
</TRANSACTION_DOCUMENT> 
<HISTORY_DOCDMENT> 
55 <History> 

<Caller name="Client"> 
<Entry me ssage=" Imported order from host erp" datetime="2000- 
01-17" status="Success'7> 

<Entry message="Set order to server for processing" 
60 datetime="2000-01-17" status="Success'7> 
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</Caller> 

<Caller name="Listener Factory "> 

<Entry message="Order pickedup by the ListenerFactory for 
processing" datetime="2000-01-17 " status="Attempt"/> 
</Caller> 

<Caller name="850Processor"> 

<Entry message="Inserted order into the ERP system, run time 
was 11 seconds." datetime="2000-01-17" status="Attempt"/> 
</Caller> 
</History> 
</HISTORY_DOCUMENT> 
<CLIENT_CONFIGURATION> 
<CLIENTHEADER> 

<TRANSPORT classname = 
"com . dotconnect . transport . ClientSMTPTransport "> 

<LISTENER classname = 
"com. dotconnect . listener . SMTPInboundListener" 



"/usr/home/rbloyer/tenetdest"> 

</LISTENER> 



<LISTENER classname = 
"com. dotconnect . listener . DirectoryListener" 



"/usr/home/rbloyer/tenet850src/"> 

</LISTENER> 



</ TRANS PORT > 
<PO0LC0NF> 



sourceurl = 



sourceurl = 



<POOL classname : 
"com. dotconnect .pool . JMSSessionPool" 



"promedix . jms . InboundJMS " 
"promedix . jms . OutboundJMS " 
"t3s://smurf :7003"/> 

<POOL classname = 



canautostart = "true" 
cankill = "true" 
def aultpoolsize = "5" 
inboundtopic = 

outboundtopic = 

provider_url = 



"com. dotconnect .pool. ThreadPool" 
usethreadpooling = "false" 
defaultpoolsize = "9" 
incrementinst = "5"/> 



</P00LC0NF> 

<REGISTRY> 

<CL I ENT_DOCUMENT type = "850" 
xsldocument = "/usr/home/rbloyer/tenetxsl/850.xsl" 
mapdocument = "/usr/home/rbloyer/tenetmap/850map. xral" 
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conversionclass = "com . dot connect . conversion . FixedLengthLoader " 
selector = "850" 
, regexp = " . *order . * | . *850\ . xml$"> 

<ADAPTER classname = 
"com. dotconnect . adapter . SMTPSendAdapter" 

version = "1 . 0" 
date = "" 
expdate = "" 
partner = "" 
author = "" 
isvalid = "" 
optl = "" 
opt2 = ""/> 

</CLIENT_DOCUMENT> 
<CLIENT_DOCOMENT type = "855" 

xsldocument = "/usr/home/rbloyer/tenetxsl/855 . xsl" 

mapdocument = "/usr/home/rbloyer/tenetmap/855map.xml" 

conversionclass = "com. dotconnect . conversion . FixedLengthLoader" 

selector = "855" 

regexp = " . *ack. * | . *855\.xml$" 

sourceurl = "/usr/home/rbloyer/tenetdest"> 

processlnstruct = "/usr/batch/load855 . sc" 

<ADAPTER classname = 
"com . dotconnect . adapter . Def aultReceiveAdapter" 

version = "1 . 0" 
date = "" 
expdate = "" 
partner = "" 
author = "" 
isvalid = "" 
optl = "" 

opt2 = ""/ 

</CLIENT_DOCUMENT> 
<CLIENT_DOCUMENT type = "832" 
xsldocument = "832. xsl" 

mapdocument = "/usr/home/rbloyer/tenetmap/832map . xml" 
conversionclass = "com. dotconnect . conversion. FixedLengthLoader" 
selector = "832" 
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regexp = " . *catalog. * | . *832\ . xml$" 

sourceurl = "/usr/home/rbloyer/tenetdest"> 

<ADAPTER classname = 
"com. dotconnect . adapter . DefaultReceiveAdapter" 

version = "1.0" 
date = "" 
expdate = "" 
partner = "" 
author = "" 
isvalid = "" 
optl = "" 
opt2 = ""/> 

< /CLI ENT_DOCUMENT> 
</REGISTRY> 

<PROPERTIES lastmodified = "0"> 
<PARTNER 

custcode = "999999" 
conpar.yname = "Empire" 
contactname = "DarthSidius" 
contactphone = "way-long-distance" 
contactemail = "dsidius@deathstar.com" 
processingbox = "devmail@promedix.com" 
monitorrecipients = "rbloyer@promedix.com" 
errorrecipients = "rbloyer@promedix.com" 
cycletime = "10000" 
clientversion = "1.0" 
serialnumber = "123456789"/> 

<MAILCONFIG 

cansendmail = "true" 
smtphost = "sherbet.promedix.com" 
pophost = "sherbet.promedix.com" 
imaphost = ""/> 

<FILES 

keyfile = "com/dotconnect/conf ig/smtpkey . ser" 
securefile = 
"com/dotconnect/config/promedix_sintp. ser"/> 

<L0GS 

enablelogging = "true" 
clientlog = "client.log" 
errorlog = "err. log" 

/> 

</PROPERTIES> 
</CLIENTHEADER> 
</CLIENT_CONFIGURATION> 
</TRANSACTION> 
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Electronic Commerce Signals 

Figure 4 illustrates an electronic commerce signal 300 in greater detail. As with the 
other Figures, components shown may be omitted, repeated, renamed, and/or grouped 
differently in different embodiments of the invention, unless called for by the relevant claims. 
5 The illustrated electronic commerce signal 300 includes electronic commerce 

transaction data 400. Suitable transaction data 400 includes, without limitation, data which 
partially or completely defines a purchase order, order status inquiry, invoice, payment, 
catalog request, and/or catalog fulfillment for electronic commerce between separate entities. 
The data 400 is in a self-documenting format, using a language such as XML. 

10 The illustrated electronic commerce signal 300 also includes a transaction type 

identifier 402 which identifies the type of commercial transaction to which the signal 300 
pertains. This type identifier 402 may be separate from the transaction data 400 as illustrated, 
or it may be part of the transaction data 400 in other embodiments. Suitable identifications 
include those corresponding with the transaction data 400 possibilities noted elsewhere 

15 herein, such as "purchase order" and "invoice". The transaction type identifier 402 may be 
implemented using bitflags, ordinal numbers, predefined text strings, or other familiar 
operation or record type identifier means. 

The illustrated electronic commerce signal 300 also optionally includes electronic 
commerce routing instructions 404. These instructions identify the target trading partner by 

20 name or in another manner convenient to non-technical users of the novel system. The hub 
server 110 translates the non-technical destination identifier 404 into IP addresses, URLs, 
Ethernet addresses, and/or other computer network addresses using a simple lookup table or 
other familiar technique adapted for use according to the present invention. 

The illustrated electronic commerce signal 300 also optionally includes electronic 

25 commerce processing instructions 406. For instance, the instructions 406 may specify email 
addresses or pager numbers for people to be notified when a purchase order arrives at a 
vendor client entity 102. The instructions 406 may identify an application 106 at the client 
entity 102 to process data after the client 108 creates a file in the buffer 114, and call that 
application 106. The instructions 406 may identify a database instance 1 14 at the client entity 

30 1 02 to receive data 400, and insert the data 400 directly into the database. 

The illustrated electronic commerce signal 300 also includes a substantially complete 
history of the commercial transaction thus far 408. For instance, the history 408 specifies the 
current settings of the remote software 108, the currently installed software adapter(s) 204 
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and/or 206, and the currently activated transaction type(s) 402. An example is provided in the 
XML HISTORY_DOCUMENT above. 

Example Using a Purchase Order and Invoice 

5 To further illustrate the invention and with reference to earlier Figures, Figure 5 

presents a data flow diagram showing communications 1 12 between clients 108 and the 
server 110, and also showing other aspects of the operation of an inventive hub & spoke 
architecture. At a client entity A, a client A obtains 500 purchase order data from A's single- 
entity transaction system 106. This may include, for instance, reading purchase order data 

10 such as vendor name, part identifier, and desired quantity from a disk or other buffer 114. 
Client A then embeds 502 the purchase order data in self-documenting form in a 
communication 112, translating from the system 106 format to the hub-client format using an 
adapter 204. The embedded purchase order data is an example of electronic commerce 
transaction data 400. The history 408 is updated. Authentication data 306 and/or error 

15 management data 304 are generated if called for by the embodiment. Then client A sends 504 
the resulting communication 1 12 to the hub 110, using the transport adapter 206 and the 
underlying computer network. 

The hub server 1 10 processes 506 the incoming purchase order 1 12. In a given 
situation and a given embodiment, this may include translating a high-level destination ID to 

20 a network address; sending a confirmation receipt to a client A; noting a purchase order's 
arrival time in case the purchase order is not acknowledged by client B quickly enough; and 
sending data to the ERP module 1 16. A detailed example of hub processing 506 is illustrated 
in Figure 10 and discussed below. 

As indicated by a step 1000, the server 1 10 accepts the incoming data through a 

25 variety of transport mechanisms, but the eventual target of each of these is a persistent 

storage area that is easily manageable, such as storage on a hard disk or in a RAID unit with 
message queues or database tables. In one embodiment, the act of acceptance and conversion 
of the transmission 1 12 into a transaction is inherent in the process of placement 1000 into 
the queue mechanism. Therefore one has a transaction in the queue. In one embodiment, 

30 successful addition of the purchase order transaction (for instance) to the queue generates 

another transaction that is delivered to the client 108 as a transmission 1 12 to confirm receipt. 

During a step 1002 the hub de-envelopes or breaks out the history 408 and routing 
information 404 embedded 502 in the transaction. The history data 408 is then secured 1004 
20 
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into a transaction management system to allow for proactive administration of the transaction 
via the history data. When this is accomplished a history event is added 1004 to the history 
408 indicating that the hub server 1 10 is now managing the transaction life cycle. 

During a step 1006 the hub identifies and uses the transaction type and customer 102. 
5 One embodiment of the hub 1 10 uses information retrieved from the transaction data 400 to 
look up 1006 the proper processing instructions in a central database at the hub 1 10; in other 
embodiments the information is stored elsewhere in the signal 300 or the hub 110. 

The hub compares 1008 the current step in transaction processing (e.g., "receive 
purchase order") with the instruction step(s) obtained during step 1006, to identify 
10 dependencies, namely, to determine whether some instructions depend on the result of other 
instructions for their input. If so, the instructions that provide required input are completed 
before the instructions that depend on the input. 

The hub server. 1 1 0 executes 1 0 1 0 the defined steps for internal processing of the 
document. In the case of a purchase order, for instance, the look up 1006 would indicate that 
15 the next step in the process after creation is data validation (checking for out-of-range values, 
verifying checksums and/or digital signatures, etc.) . Data validation is performed during an 
instance of illustrated step 1010 by executing code which is associated by the hub 110 with 
the processing step dynamically in response to at least the transaction type. 

Once the data is validated the next step is looked up 1006 and executed 1010 in a 
20 similar fashion. For example, the next step could be to submit data 400 to the ERP system 
116 through a conventional API defined within the ERP system. This would be executed in a 
synchronous fashion, with the hub 1 1 0 awaiting a response from the ERP system 116. The 
response could be a simple success or failure statement from the ERP system 1 16 to the hub 
server 110. 

25 Each step in the process looked up during illustrated step 1006 has a similar 

executable code association for use with illustrated step 1010. As shown in Figure 10, 
exception handling code is preferably provided to deal with failed process steps, and this is 
preferably done regardless of whether the failure is data related or process execution related. 
The exception code moves 1012 the transaction to a persistent storage designated to hold 

30 exception-related transaction and processing information. An administrator or engineer can 
then examine the information to determine what caused the exception and how to respond 
further to the exception. 
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Once successful submission of the purchase order has been achieved the server 110 
moves 1014 the transaction to a holding area (queue) that maintains the transaction. The hub 
1 10 then awaits a purchase order acknowledgement, or does whatever is defined as the next 
step for the document in the transaction processing definition. For example, the hub could 
5 await the purchase order acknowledgement from the supplier/vendor 102. Once the 

acknowledgment 1 12 is received and processed, the server 110 would move to the next step, 
and so on. Of course, in particular instances or embodiments, the steps shown in Figure 10 
may be reordered, performed concurrently, omitted, renamed, and/or regrouped, in ways that 
will be apparent to one of skill in the art. 

10 In general, an architecture 100 according to the present invention could be 

implemented with a hub 1 10 for which a processing path is defined using a modeling tool like 
Unified Modeling Language ("UML"). This approach generates new code for each step and 
stores that code for future use. However, this may be relatively inefficient due to the large 
code base and duplication of code it suggests. 

15 Accordingly, other embodiments of the system 1 00 store a step or event in the 

business process lifecycle (e.g., purchase order lifecycle) as a database entry in a 
communication 1 12 that refers to an existing generic piece of code. The hub 110 executes 
that code with partner, processing instruction step, and process as parameters, as illustrated in 
Figure 10, for example. This method allows a web based process modeling tool to be built, 

20 similar to a mapping website, to define how the system 100 should track the process of 

executing the purchase order lifecycle. Whereas the UML approach might be marketed with a 
claim that "no coding is necessary" at a client 102, the latter approach could claim "no 
systems or servers are necessary" there because the business process is modeled at the central 
hub 110 and executed at the central hub 110. This process modeling functionality could be 

25 distributed to the clients 108 as a "processing model" transaction. This use of references (as 
opposed to the UML approach) is a preferred implementation of the processing instructions 
406 embedded in the document 300. That is, the embedded instructions 406 refer to the 
executable instructions performed 506/610/612 by the hub 110, allowing one to modify the 
process model at the client 108 and then activate it by a simple instruction in the transaction 

30 signal 300. 

Then the hub server 110 sends 508 the purchase order data in a communication 1 12 to 
the vendor client entity B. Client B extracts the purchase order data, and submits it to B's 
system 106. In response to the purchase order, the system 106 generates an invoice. Client B 
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obtains 510 the invoice data from B's system 106, embeds 512 it in a communication 1 12 
(converting the invoice data format to an XML format used by the hub 110), and sends 514 it 
to the hub 110. The hub processes 516 the invoice communication as discussed above 
(another step in the hub processing) and sends 518 the invoice data to client A. 

5 

Methods 

Figure 6 illustrates methods of the present invention. Steps shown may be omitted, 
repeated, performed concurrently, reordered, combined, and/or renamed in a particular 
embodiment, to the extent that the invention continues to operate and also to the extent 

10 permitted by the claims. It will also be appreciated that discussion herein of one category of 
embodiment (e.g., method, architecture, configured storage medium, or signal) of the 
invention will often be helpful in understanding other categories of embodiment. Unless 
indicated otherwise to one of skill, therefore, discussions of the methods also pertain to the 
architecture and signals, discussions of signals also pertain to the methods and architecture, 

15 and so on. 

During a hub configuring step 600, the hub 1 10 is initialized according to a definition 
of the business process model the hub is to implement, including the order in which 
transactions are to be executed, and the expected steps in each document lifecycle. Also 
mapping of the documents and their translation could be executed at the hub and stored there 
20 for delivery. For instance, mapping defines field relationships so the client 108 can convert 
data between XML and an internal client 102 format. 

During a client 108 installing step 602, client 108 software is installed on computer 
hardware, the client 108 is connected to the underlying computer network to permit 
communication with the hub server 110, and the client 108 is given access permissions, 
25 connections, and/or other capabilities so it can exchange transaction data with the entity's 
transaction system 106. Embodiments having pluggable adapters 204, 206, may use a single 
client 108 installation regardless of formats and/or transports used; the client 108 is 
configured with downloadable adapters after installation of the data processors 200, 202. 
During a related updating step, the client 108 software is updated to include, for 
30 instance, more or different adapters 204, 206. The updating step is combined in the 
illustration with the installing step, but may be viewed as a separate step in other 
embodiments. Automated client 108 updates are driven by configuration changes, not by an 
update engine. That is, the client 108 can make changes to itself, or the server 1 10 can make 
23 
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changes to the client 108. In either case the changes are reflected to the other system 100 
component. This allows the server 1 10 to be synchronized with client 108 changes, and 
makes it possible to do mass updates in the system 100 by changing the server 110 
configuration and having that change reflected to all clients 108. 
5 From the client entity 102 perspective, the installation process that integrates them in 

the novel architecture 100 may proceed generally as follows. A new or existing customer 102 
chooses to "integrate" by expressing this desire to their sales representative or by choosing 
the appropriate service on the service provider 104 web site. The entity 102 must exist in the 
system as a customer before integration can begin. That is, an identifying account that 

10 controls access to the web site configuration tools must exist before integration can occur. 
The integration web site is not a stand-alone site but requires another site to be the homepage 
and authentication master. A transaction monitoring module in the hub 110 receives an entry 
from an installation web site or installation software package indicating that this customer 
102 has begun integration. As integration commences, the customer 102 is presented with a 

15 series of choices and questions. After answering the questionnaire, customer 102 is presented 
with an installable software package 108. This is another form of a monitored transaction 
where response time and transactional completeness are "guaranteed" by the monitoring 
system. 

The installation of the client 108 occurs by direct install online, or by a download 
20 followed by a local install, using familiar software transfer and installation tools and 

techniques. During installation the customer 102 is asked more questions about configuration 
(e.g., host machine, network address to send transactions to and from, name of company, 
technical contact info, directory or database to look in for transactions). The installation 
completes and the configuration is sent as a transaction back to the server 110. The client 108 
25 is now installed and the server 110 receives the configuration transaction. An initial test 

document is sent to the new client 108 automatically; one suitable test document is a catalog 
with only one item. The client 108 confirms receipt of this test catalog. A transaction monitor 
in the hub 1 10 is thus notified that integration installation has completed successfully. 

At this point, the transaction monitor is also notified that mapping has started. An 
30 email or other message from a service provider 104 integration specialist points the user 102 
at an integration web site, Using forms at the web site, the user 102 chooses an output format 
and document type, and defines output format specifics such as field locations, data elements, 
and so on. This may be repeated for multiple documents. The user submits a completed 
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translation map to the hub 1 10 for testing. The hub 110 generates a sample document using 
the mapping. The sample document is sent to the client 108 for testing. The transaction 
monitor is notified that the format translation mapping is being tested. The user 102 returns to 
the web site, makes changes and repeats the test as need, and ultimately agrees with the 
5 document format conversion map(s). The transaction monitor is accordingly notified that 
mapping has completed for the document type in question. Finally, the document type and 
customer 102 status are changed to "production, ready for mapped document". 

During an obtaining step 604, the client 108 obtains initial transaction data 400 from 
the system 106. For instance, the client 108 may obtain 500 purchase order data. In some 

10 embodiments, the purchase order data is generated in response to choices made by a buyer 
using a service provider web site 120 and/or a purchasing interface of the client 108. This 
allows buyers 102 to do some or all of the following: evaluate products from one or more 
vendors in side-by-side comparisons; search product catalogs by manufacturer, product 
number, product description, or some combination thereof; create a "favorites" list of 

15 products that are ordered often; duplicate previous orders entirely or with specified changes; 
make personal notes on specific products, to help remember which personnel prefer which 
product, for example; and access the entity's buying history to identify trends in product 
usage, for instance. 

The website client 120 may be furnished by the same service provider 104 that 
20 furnishes the hub 110. However, from the perspective of the hub 1 1 0, the website 1 20 is just 
another client 102 that submits orders. Indeed, the website client internal architecture 
includes a client 108, a buffer 14, and some type of order placement software, such as a 
purchasing interface that includes Internet browser forms and accompanying Java or CGI 
order placement code. When someone places an order on the web for product that is not 
25 included in the system 1 06 catalog the hub 1 1 0 sends a micro-catalog to them before the 
XML order, to make sure they have the products in their item master in their ERP system. 

During an embedding step 606, the client 108 performs any necessary format 
conversion to a self-documenting format and embeds the reformatted transaction data 400 in 
a communication 1 12. 

30 During a sending step 608, the client 108 sends the communication 1 12 over the 

computer network "wire" to the hub server 1 10. 

During a processing step 610, the hub server 1 10 processes the communication 1 12 by 
reading the embedded routing information, customer ID and document type, selecting server 
25 
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stored information about this partner and executing the appropriate business logic. Other 
processing steps may be executed as deemed necessary by the profile of the partner or as 
embedded in the transaction. For instance, in the XML file above a line that reads 
"processlnstruct = 7usr/batch/load855.sc"" illustrates the ability of the client 108 to specify a 
5 program at the remote location 102 to execute processing instructions as a hub 1 1 0 
processing step. For convenience and to emphasize its optional nature, a procurement 
accounting step 612 is shown separately. As discussed earlier, in some embodiments the step 
612 and the step 610 are grouped together as a single processing step, such as the step 506. 
Figure 10 illustrates detailed steps for hub processing 610, 612 in one embodiment; the steps 

10 shown in Figure 10 are discussed at least in connection with Figure 5 above. 

Steps 614 to 632 proceed in a similar manner. Step 614 sends a communication 1 12 
from the hub 1 10 to the client 108. For simplicity, a single client B is denoted in Figure 6, 
but a single purchase order may result in order communications 1 1 2 to one or more vendors 
102. On receiving the communication, the target client 108 extracts 616 the transaction data 

15 from the message 1 12 and presents 618 the data to the client 102 system 106. If there are 
additional processing instructions, such as notification of personnel at client B, these are 
carried out 620. If this is the end of the business lifecycle for the transaction in question, 
processing ends as indicated by the arrow after step 620. For instance, the communication 
just processed 620 may have been a confirmation that requires no further communication 

20 back to client A. 

However, if the communication calls for a response under the business process model, 
then client B may obtain 622 responsive data (such as an order confirmation number) from its 
local system 106. Client B embeds 624 that data in an XML or similar format in a responsive 
communication 112, and sends 626 it to the hub 110. Client 108 interaction with the system 

25 1 06 through a buffer, format conversion during step 624, and transmission methods using 
adapters 206, for instance, proceed as discussed elsewhere herein. The hub 110 likewise 
processes 628 the responsive communication as discussed in connection with illustrated step 
506 and elsewhere herein. The hub then sends 630 a corresponding communication 112 back 
to client A, which extracts 632 it, and then proceeds accordingly in view of the 

30 communication 112 content and the business process model that defines the lifecycle for the 
transaction in question. 
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Proactive transaction monitoring and exception handling steps 634 are performed as 
needed through the illustrated steps 600-632. These steps are discussed elsewhere herein in 
connection with notifications, with timeouts, and with Figure 10, for instance. 

A monitoring and exception handling step 634 may be performed, or partially 
5 performed, at one or more various points in the sequence just described. In one embodiment, 
upon receipt of the transaction data 400 it is persistently stored in a location such as a hard 
disk. This location indicates the transaction 400 arrival time. If the defined response time for 
a given transactional step expires without a detected response, then the monitoring system in 
the hub 1 10 or client 108 reacts by sending out notifications of an expired transaction. This 
10 can include automated notification to the integrated system 100, email notification to an 
account manager either in the partner 102 or the service provider 1 04. Further steps will be 
taken if an exception response time expires. For instance, the system 100 may reroute the 
transaction to an alternate partner 102 or cancel the transaction and provide notification of 
these events in the same fashion as above. 

15 

Implementation Development History 

A first implementation of the invention included four classes, and was designed using 
a traditional procedural design methodology. Functionality characteristics included single 
threaded message (prototype communication 1 12) processing, a single output format per 

20 message, and adapter 204 support for converting XML to EDI, and converting XML to 
delimited file output formats. 

This implementation included a total of four objects that when instantiated, made a 
connection to a specified mailbox, and processed mail messages based on configuration 
settings taken from a properties file. Mail messages were retrieved by the client 108 based on 

25 subject heading criteria and were processed in a single threaded mode. Processing involved 
polling a mail server and retrieving the message 1 12 body, looking up the processing 
direction from a properties file, parsing the body and writing the result to a disk file 1 14. This 
implementation supported only one processing direction, namely, from XML to EDI or from 
XML to plain text or a comma delimited format. 

30 A second implementation included eleven classes, and was designed using an object 

oriented design methodology. Its functionality characteristics included multithreaded mailbox 
connection, single threaded message 1 12 processing, multiple output formats per message, 
properties file delivery to a hub server 1 10 operated by Promedix.com (assignee of the 
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present invention), processing response email, a consistent internal order object, adapter 204 
support for EDI to XML conversion, and for conversion from XML to a Java order object. 

This second implementation included a total of eleven objects that worked together in 
a more complete object oriented fashion. One managing object in the client 108 controlled 
other objects that made a connection to a mail server, processed any retrieved messages, and 
output into resultant formats. Connections to the mail server occurred in child threads forked 
by the managing object. Within an individual child thread, the message body was retrieved 
and passed to an object that processed the message into one or many formats indicated by 
settings in a properties file. These resultant formats included conversions from EDI to XML, 
and conversions from XML into a Java order object. The Java object could then be converted 
into a file with any selected delimiter, or any other customized format. In addition to the 
processing of the message body, a response email with the results of the processing or any 
exception/error messages could optionally be sent to one or many email addresses. This 
iteration also monitored and sent its properties file to the Promedix.com hub server 1 10 for 
record keeping purposes. 

A third implementation included thirty classes, and was designed using methodology 
directed toward a "black box" application framework design with a publicly available 
Application Programmers' Interface ("API"). Its functionality characteristics included a 
"pluggable" (i.e., modular, separable) transport protocol layer for protocol independence 
through transport adapters 206, a pluggable adapter 204 layer, registration and dynamic 
update of adapter classes, internal XML configuration and operation semantics, a publicly 
available API, encryption support, and event logging. 

This third implementation represents a fundamental re-design over previous iterations. 
This implementation's design is a "black box" application framework. Transport layers and 
adapters can be plugged in (and out) through a publicly available API set, extending the 
functionality of the software to meet customized needs. The supported transport layer 
includes client transactions through traditional Simple Mail Transfer Protocol ("SMTP") 
services; suitable alternatives include adapters 206 for Remote Method Invocation ("RMI") 
socket use; HyperText Transfer Protocol ("HTTP"), File Transfer Protocol ("FTP"), or other 
socket-to-socket connections; and other protocols as necessary. Functionality is also 
extensible through pluggable format adapters 204. These adapters 204 are plugged in and 
executed in child threads enabling processing to any output format necessary. Output formats 
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of the adapters 204 support Java Database Connectivity ("JDBC") connections, output into 
XML or delimited files, and "screen scraping" support to extract data from screen drivers. 

In support of the publicly available API set, and the dynamically loaded transport and 
adapter layers, this implementation executes an internal registry service that monitors and 
5 updates classes by sending or "pushing" its current state to the hub server 1 10. If the hub 
server identifies a requirement for update, it sends the required class to the client 108 as a 
response. The required classes are received, registered, and loaded for execution. The registry 
uses client-specific, dynamically built XML documents from the hub server in its 
communication with the server to request and load transport and adapter classes that may be 
10 new, updated, or installation-specific. 

This implementation can also use any encryption standard from a provider that has 
Java-enabled their encryption algorithm classes. Encryption is used for all incoming and 
outgoing messages, regardless of transport protocol. Currently synchronous keys are being 
used, however, asynchronous public-private keys can be generated and used if needed. 
15 Event logging of current execution and exception/error state is also performed in this 

implementation. 

Additional Client and Architecture Examples 

Figure 7 illustrates an architecture according to the present invention during use by a 
20 transaction community for a market in medical products. A client 108 at a hospital exchanges 
data through a disk buffer 1 14 with a transaction system 106. The invention is compatible 
with conventional approaches, in the sense that it can be used in combination with them. 
Thus, in addition to the invention the hospital 102 also uses the buffer 1 14 with a 
conventional EDI gateway communication system 700 to exchange EDI data directly over 
25 conventional value added network 702 with EDI trading partners 704. 

With further attention to the invention, the hospital 102 sends and receives 
communications 1 12 by email through an otherwise conventional email server 706 that is in 
turn serviced by a conventional router 708 and protected by a conventional firewall 118. The 
firewall 1 1 8 is prudent because the hospital 102 communicates with other transactional 
30 community members 1 02 in part through the Internet 710, which is generally open to the 
public but also less expensive and easier to use than many value added networks. The 
communications 1 12 travel over the Internet 710 to the hub 1 10, and communications 112 
likewise travel over the Internet 710 between the hub 1 10 and other client entities, such as 
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vendors 102 which are not direct EDI vendors but instead use the invention for electronic 
commerce with the hospital 102. 

The illustrated embodiment includes a procurement module 1 16 at the hub 1 10. The 
illustrated procurement module 116 includes a conventional enterprise resource planning 
5 system 712 and a conventional warehouse management system 714. Other embodiments may 
use other software and/or omit one or more of the illustrated systems. 

Figure 8 further illustrates data flow within a client 108 embodiment. An incoming 
data processing flow 800 may be performed with the incoming data processor 200, and an 
outgoing data processing flow 802 may be performed with the outgoing data processor 202. 

10 The email server 706 receives email messages and places them in one or more mailboxes 804 
using conventional techniques. The incoming data processor 200 checks 806 the client 108 
mailbox 804 for messages. This may be done by background polling, as indicated, by 
interrupts, or by other familiar techniques. If any email messages are found in the mailbox 
804, they are checked 808 to determine if they are electronic commerce communications 112 

15 or other messages pertaining to the invention. If they are communications 1 12, their 

transaction data 400 is extracted (as during steps 616, 632, for instance) and formatted for the 
client entity's internal transaction system 106 (using a format adapter 204, for instance). The 
transaction data 400 is presented to the system 106 in this case by writing 812 the data 400 to 
a disk 1 14. An acknowledgement or other status update is also sent 814 by email to the hub 

20 110, informing the hub 1 10 of the status of the transaction at the client 108. 

During outgoing data processing 802, the outgoing data processor 202 operates in a 
similar manner. The disk 1 14 is checked 816 for files that may contain transaction data 400. 
If it is determined 818 that data 400 has been presented to the client 108 by the client entity's 
internal transaction system 106, then the client 108 imports 820 the data 400, does format 

25 conversion 822 as needed to place the data 400 in an XML or other self-documenting format, 
embeds the data 400 in a communication 1 12 and sends 824 the communication 1 12 to the 
hub 1 10 as an email message. 

Figure 9 further illustrates steps and structure in a client 108 embodiment. During an 
initialization step 900, the client 108 reads a registry and loads all installed adapters 204, 206 

30 into memory. During a step 902, the client 108 then reads properties from disk. Properties 
may specify, for instance, notification addresses, directories 1 14 to read from, directoriesl 14 
to write to, and/or configuration information for transport types and listeners. The client 108 
also checks to see if adequate disk space is available, and attempts to open an email 
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connection with the email server 706. As illustrated, if the email connection attempt fails 
(possibly after retries) then the client 108 notifies 904 a designated administrator or technical 
contact using a previously specified email address, and preferably also notifies the hub server 
1 1 0 by alternate email or other means. If the email connection is established but the client 
5 108 lacks necessary disk space or detects an error in the properties, then the client 1 08 
notifies 906 the hub 1 1 0 of the error by email. 

If no errors are detected, the client 108 enters and repeats a main loop 908. The loop 
checks 910 for email messages, as discussed for instance in connection with Figure 8. If a 
communication 112 is received, the illustrated client 108 spawns 912 a separate thread 916 to 
10 process the incoming data 400. The main client loop also notifies 914 the hub 110 of status at 
suitable times. For instance, the hub 1 10 may be notified 914 that the communication 1 12 has 
been received, may be notified 914 that the transaction data 400 within the communication 
has been processed (by the thread 916), or both. 

In the illustrated embodiment, the thread 916 receives 918 the email message as an 
1 5 email obj ect. The thread 9 1 6 parses 920 a document obj ect out of the email message. The 
document object contains the transaction data 400, history, routing, processing instructions, 
and so on. The thread 916 then parses the document object into a Java object. This facilitates 
use of a format translation engine based in Java. More generally, the thread or other process 
places the translation data 400 in memory for format translation by a translation engine into a 
20 format usable by the legacy system 1 06. Finally, the thread 9 1 6 writes the formatted data 400 
to the buffer 1 14 to present it to the client entity's local transaction system 106, and sends 926 
status back to the main loop 908 so the hub 1 1 0 can be notified. 

Additional Commercial Document Examples 

25 It will also be appreciated that the invention can be used to advantage with various 

types of business documents. To further illustrate the inventive architecture, 
methods/configured media, and signals, several additional examples of the invention in 
operation are described below. It is not necessary for every embodiment of the present 
invention to support every document type discussed here, to contain the exact components 

30 mentioned, or to perform the precise steps listed. These are merely examples that illustrate 
possible embodiments. 
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Inbound Purchase Order 300 from Customer 102 to E-Commerce Service Provider 104 

The inbound purchase order from a customer 102 to the hub 1 10 is a common 
document that will be implemented in many embodiments. Even the most rudimentary 
systems 106 support some form of purchase order output. The basic process may be 
5 modified, but the following describes a simple flow. The processing of transactions in a 

preferred embodiment is the same for all business documents and all directions (buyer toward 
seller or vice versa), in the sense that the processing instructions are abstracted into the hub 
110 database and the hub just walks through a process definition table and executes steps 
accordingly, as discussed, for instance, in connection with Figure 10. The steps outlined 
10 below are examples; they could be different for various customers and suppliers: 

1. Order created in a materials management ("MM") remote ERP system 106 

2. Supplier information is verified against supplier master 

3. Validation of order items against item master, including pricing 

4. Routing for order defined - potential for external routing mechanism 
15 5. Extract order for external delivery (file, fax, voice, printer, EDI, etc.) 

6. Notification or discovery of extracted order 

7. Acquisition of file 

8. Conversion of file into usable intermediate format based on local mapping data 

9. Combination of data with local routing information 
20 1 0. Combination of data with local mapping data 

1 1 . Discovery of routing info 

12. Encryption of data, mapping, routing into communication 1 12 

13. Deliver communication 1 12 to host 1 10 via identified routing and transport 

14. Decrypt communication 1 12 during receipt of information 
25 15. Receive into queue through transport handler/listener 

1 6. Reply to client with confirmation of receipt 

17. Pull transaction from queue 

18. Submit order to ERP system through server 1 10 services 



30 Purchase Order Delivered to Supplier 102 from E-Commerce Service Provider 104 

In some embodiments, the inbound purchase order received from a customer into the 
service provider's system will be entered as a sales order. This sales order will then be 
converted into a purchase order to be sent out to the supplier 102. The outbound purchase 
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order is a common document that will be implemented in many embodiments; even the most 
rudimentary system 106 supports some form of order entry. The basic process may be 
modified, but the following describes a simple flow. 
1. Purchase order created in ERP system 116 (automatic or manual) 
5 2. Supplier information verified against supplier master 

3. Validation of order items against item master including pricing 

4. Extract order for external delivery (delivery to file system or Java Message Service 
("JMS") queue) 

5. Notification or discovery of extracted order 
10 6. Acquisition of file/document 

7. Discovery of routing info/Routing for order extracted from database 

8. Combination of data with routing information 

9. Combination of data with mapping data 

10. Encryption of data, mapping, routing into communication 112 
15 11. Transaction handed to proper delivery adapter 206 

12. Deliver communication 1 12 to host 1 10 (hub server) via identified routing and transport 

13. Decrypt communication 1 12 during receipt of info 

14. Receive into client 108 at supplier 102 through transport handler/listener 

15. Find proper adapter based on document 
20 16. Load mapping info 

17. Convert document based upon mapping info 

18. Execute adapter output (e.g., write file to disk 1 14) 

19. Reply to host with confirmation of receipt 

20. Notify supplier ERP system of transaction arrival - optional 

25 

Purchase Order Acknowledgement Submitted by Supplier 102 to E-Commerce Service 
Provider 104 

The inbound acknowledgement of purchase order is a common document that will be 
implemented in many embodiments. The basic process may be modified, but the following 
30 describes a simple flow. 

1 . Purchase order acknowledgement created in supplier's system (automatic or manual) 

2. Routing for order defined - potential for external routing mechanism 

3. Extract order for external delivery (file, fax, voice, printer, EDI, etc.) 
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4. Notification or discovery of extracted order 

5. Acquisition of file 

6. Conversion of file into usable intermediate format based on local mapping data 

7. Combination of data with local routing information 
5 8. Combination of data with local mapping data 

9. Discovery of routing info 

10. Encryption of data, mapping, routing into communication 112 

1 1 . Deliver communication 1 12 to host 1 10 via identified routing and transport 

12. Decrypt communication 1 12 during receipt of info 

10 13. Receive into queue through transport handler/listener 

14. Reply to client with confirmation of receipt 

15. Pull transaction from queue 

16. Submit order to ERP system through server 110 services 

15 Purchase Order Acknowledgment Delivered by E-Commerce Sendee Provider 104 to 
Customer 102 

The outbound acknowledgement of purchase order from service provider 104 to a 
customer 102 is a common document that will be implemented in many embodiments. This 
acknowledgement will be sent out as soon as the supplier 102 has sent service provider 104 
20 an acknowledgement of the receipt of the purchase order. The basic process may be modified, 
but the following describes a simple flow. 

1. Purchase order acknowledgement created in ERP system (automatic or manual) 

2. Supplier information verified against original purchase order. 

3. Validation of item status against original purchase order. 

25 4. Extract order for external delivery (delivery to file system or JMS queue) 

5. Notification or discovery of extracted order 

6. Acquisition of file/document 

7. Discovery of routing info/Routing for order extracted from database 

8. Combination of data with routing information 
30 9. Combination of data with mapping data 

10. Encryption of data, mapping, routing into communication 112 

11. Transaction handed to proper delivery adapter 206 

12. Deliver communication 1 12 to host 1 10 via identified routing and transport 
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13. Receive into client 108 through transport handler/listener 

14. Decrypt communication 112 

15. Find proper adapter based on document 

16. Load mapping info 

5 17. Convert document based upon mapping info 

18. Execute adapter output (e.g., write file to disk 1 14) 

19. Reply to host 110 with confirmation of receipt 

20. Notify supplier ERP system of transaction arrival - optional 

10 Invoice Submitted by Supplier 102 

The inbound Invoice is a common document that will be implemented in many 
embodiments. The basic process may be modified, but the following describes a simple flow. 

1. Invoice created in supplier billing system 

2. Validation of order items against item master including pricing 

15 3. Routing for invoice defined - potential for external routing mechanism 

4. Extract invoice for external delivery (file, fax, voice, printer, EDI, etc..) 

5. Notification or discovery of extracted invoice 

6. Acquisition of file 

7. Conversion of file into usable intermediate format based on local mapping data 
20 8. Combination of data with local routing information 

9. Combination of data with local mapping data 

10. Discovery of routing info 

11. Encryption of data, mapping, routing into communication 112 

12. Deliver communication 1 12 to host 1 10 via identified routing and transport 
25 13. Decrypt communication 1 12 during receipt of info 

14. Receive into queue through transport handler/listener 

15. Reply to client with confirmation of receipt 

16. Pull transaction from queue 

17. Submit invoice to ERP system through server 1 10 services 

30 

Invoice Delivered to Customer 102 

The outbound invoice is a common document that will be implemented in many 
embodiments. The basic process may be modified, but the following describes a simple flow. 
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1 . Invoice created in ERP system 116 (automatic or manual) 

2. Customer information verified against account master 

3. Validation of invoice items against item master including pricing 

4. Extract invoice for external delivery (delivery to file system or JMS queue) 
5 5 . Notification or discovery of extracted invoice 

6. Acquisition of file/document 

7. Discovery of routing info/Routing for document extracted from database 

8. Combination of data with routing information 

9. Combination of data with mapping data 

10 10. Encryption of data, mapping, routing into communication 1 12 

1 1 . Transaction handed to proper delivery adapter 

1 2 . Deliver communication 1 1 2 to host 1 1 0 via identified routing and transport 

13. Decrypt communication 1 12 during receipt of info 

14. Receive into client through transport handler/listener 
15 15. Find proper adapter based on document 

16. Load mapping info 

17. Convert document based upon mapping info 

18. Execute adapter output (e.g., write file to disk) 

19. Reply to host with confirmation of receipt 

20 20. Notify customer ERP system of transaction arrival - optional 

Additional Business Processes 

The following are some of the additional business processes that may also be 
implemented in various embodiments: 
25 1 . Ability to handle user profiles (create, update, delete) 

2. Create/update customer master in ERP along with multiple ship-to and bill-to addresses 

3. Create/update supplier master in ERP 

4. Ability to create/update/delete catalog items or subset of catalog items based on a product 
category etc. 

30 5 . Ability to handle cXML, CBL etc. based purchase orders 

6. Advance shipment notifications 

7. Send and update notes (text) per line item in the ERP system 

8. Order status inquiry 
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9. Request for quotation 

10. Response to request for quotation 

1 1 . Purchase order change request - buyer initiated 

12. Purchase order change acknowledgement/request - supplier initiated 

5 

End to End Transaction Lifecycle 

The following list steps through the various states that a transaction may be in during 
its life cycle. Each step may represent a full process in an ERP system or a single step in the 
movement of the transaction. 
10 1 . Purchase order ("PO") created by customer on web site 

2. Server 1 10 receives PO through JMS posted message from web site 

3. Server 110 acquires message from queue 

4. Queue listener hands message to submit order interface 

5. Submit order bean(s) sends message into ERP through entity bean layer 
15 6. Entity beans perform system inserts and updates with rollback 

7. ERP receives order and validates account and customers 

8. Supplier purchase orders generated to fulfill the order 

9. Purchase orders extracted from ERP to disk or JMS queue 

10. Server 110 picks up outbound PO's and discover routing information 
20 11. Transaction is enveloped to include routing and mapping info 

12. Transaction is delivered to the partner (supplier) via transport adapter 

13. Individual suppliers receive transactions via transport adapter 

14. Supplier's installed' client 102 receives transaction and confirm receipt by response 

15. Client 102 writes data to disk or database 1 14 

25 16. Supplier ERP 106 processes order and generates internal response 

17. Response to order is written to disk 1 14 

18. Client 108 picks up order and converts to internal format 

19. Client 108 encrypts the response and delivers to host 1 10 

20. Host 110 decrypts the transaction and puts in inbound queue 

30 21. Server picks up queue entry and process line status into ERP system 

22. Generates notification to customer of change in ship status of order 

23. Customers client writes PO update information to disk and sends notification to host 

24. Customers ERP system picks up order updates and changes line item status 
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25. When ERP 116 runs invoice batch, exports invoice for this order 

26. Invoice is sent with others through outbound queue 

27. Invoice received at customer client and written to disk 

28. Notification of delivery is returned to server 1 10 

5 29. Customer ERP imports invoice and enters into AP 

30. Payment is generated by customer ERP 106 

3 1 . Payment notification is written to disk 

32. Client picks up payment notification and sends to host 1 10 

33. Payment notice is written to ERP system 1 16 

10 

Summary 

In summary, the present invention provides methods, systems, and configured storage 
media for electronic commerce. In a hub & spoke architecture such as the illustrated 
architecture 100, communications 1 12 are exchanged using XML or another self- 

15 documenting format. The communications 1 12 include electronic commerce transaction data 
400 such as purchase order data, processing instructions (which may refer to additional 
instructions stored at the hub), and a substantially complete history 408 of the transaction's 
life thus far within the architecture. By keeping the history 408 within the communications 
112 that travel around the architecture 100 instead of keeping separate histories or logs at the 

20 hub and at the client spokes, the invention permits more efficient and effective proactive 
transaction monitoring. 

Embodiments of the invention also provide other advantages. For instance, by 
allowing processing instructions to be maintained at the hub 110 and be merely referenced in 
the communications 1 12, the invention allows the processing of documents 1 12 to be tailored 

25 to the individual circumstances of each document without using unnecessary bandwidth or 
risking inconsistency between copies of the processing code. By utilizing pluggable adapters 
204 for format conversion between XML and EDI or other proprietary client formats, and 
pluggable adapters 206 for transport mechanisms, the invention makes the process of adding 
a client spoke to the hub & spoke architecture more flexible and faster than otherwise. 

30 Unlike conventional systems that simply use the Internet to transport otherwise 

conventional EDI messages, the present invention does not require that each client 108 know 
detailed information about each other client 108 for commercial communications 1 12 to be 
routed; the hub 110 maintains such information. Indeed, in a given embodiment, the hub 1 10 
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may select vendors 102 in cases where the client 102 placing a purchase order has specified 
items and item counts but has not expressly specified or limited the choice of vendor. 

Articles of manufacture within the scope of the present invention include a computer- 
readable storage medium in combination with the specific physical configuration of a 

5 substrate of the computer-readable storage medium. The substrate configuration represents 
data and instructions which cause the computers to operate in a specific and predefined 
manner as described herein. Suitable storage devices include hard disks, CD-ROMs, and 
other media readable by computers. Each such medium tangibly embodies a program, 
functions, and/or instructions that are executable by the computer system to perform steps 

10 substantially as described herein to facilitate electronic commerce. 

Although particular methods embodying the present invention are expressly 
illustrated and described herein, it will be appreciated that system and configured storage 
medium embodiments may also be formed according to the methods of the present invention. 
Unless otherwise expressly indicated, the descriptions herein of methods of the present 

1 5 invention therefore extend to corresponding systems and configured storage media, and the 
descriptions of systems and configured storage media of the present invention extend 
likewise to corresponding methods. 

In addition, the method steps discussed may be performed in various orders, except in 
those cases in which the results of one step are required as input to another step. Likewise, 

20 steps may be omitted unless called for in issued claims, regardless of whether they are 

expressly described as optional in this Detailed Description. Steps may also be repeated, or 
combined, or named differently. 

As used herein, terms such as "a" and "the" and item designations such as "client" and 
"communication" are generally inclusive of one or more of the indicated item. In particular, 

25 in the claims a reference to an item normally means at least one such item is required. 

The invention may be embodied in other specific forms without departing from its 
essential characteristics. The described embodiments are to be considered in all respects only 
as illustrative and not restrictive. Headings are for convenience only. The scope of the 
invention is, therefore, indicated by the appended claims rather than by the foregoing 

30 description. All changes which come within the meaning and range of equivalency of the 
claims are to be embraced within their scope. 

What is claimed and desired to be secured by patent is: 
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CLAIMS 

1 . A hub & spoke architecture for electronic commerce comprising a hub server 
and at least two clients, each client being a spoke of the hub & spoke architecture, each client 
residing at and acting on behalf of a different client entity, the hub server maintained by a 

5 third entity which is an electronic commerce service provider, wherein: 
the hub server comprises: 

at least one connection whereby the hub server receives 
communications from the client entities and sends communications to the 
client entities, the communications from the hub server being sent in 
10 accordance with the respective business roles of the client entities, the 

communications comprising encapsulated process information; 

the encapsulated process information in at least one of the 
communications comprising electronic commerce transaction data in a self- 
documenting format and also comprising at least one of (a) a substantially 
1 5 complete history of that electronic commerce transaction data within the hub 

& spoke architecture, (b) a processing instruction reference identifying code at 
the hub server for executing instructions to process that electronic commerce 
transaction data, and (c) a specification of at least one item which does not 
specify a vendor for the item, the hub server instead selecting a vendor for the 
20 item, the vendor being within the hub & spoke architecture; 

and 

each client comprises: 

an incoming data processor which checks for incoming 
communications from the hub server, extracts electronic commerce transaction 
25 data from such communications, and posts the data to a single-entity- 

transaction-system; and 

an outgoing data processor which checks for outgoing electronic 
commerce transaction data from the single-entity-transaction-system, embeds 
at least part of the electronic commerce transaction data in a communication in 
30 a self-documenting format, and sends the communication to the hub server. 

2. The electronic commerce architecture of claim 1, wherein at least one client 
resides behind a firewall at that client's entity. 
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3 . The electronic commerce architecture of claim 1 , wherein the electronic 
commerce transaction data in at least one communication uses extensible markup language to 
provide a self-documenting format. 

4. The electronic commerce architecture of claim 1 , wherein the hub server and 
5 the clients send communications to one another by email. 

5. The electronic commerce architecture of claim 1, wherein the hub server and 
the clients send communications to one another using message-based middleware. 

6. The electronic commerce architecture of claim 1, wherein the hub server and 
the clients send communications to one another using a socket-to-socket connection. 

10 7. The electronic commerce architecture of claim 1 , wherein the hub server 

receives communications by way of an inbound message queue and sends communications 
by way of an outbound message queue. 

8. The electronic commerce architecture of claim 1, wherein the incoming data 
processor posts the electronic commerce transaction data by writing it to nonvolatile storage 

15 which is also accessed by the single-entity-transaction-system. 

9. The electronic commerce architecture of claim 1 , wherein at least one client 
comprises a dynamically loaded transport layer which facilitates transport of communications 
between the client and the hub server. 

10. The electronic commerce architecture of claim 1, wherein at least one client 
20 comprises a dynamically loaded format adapter which converts electronic commerce 

transaction data between the self-documenting format and an electronic data interchange 
format. 

1 1 . The electronic commerce architecture of claim 1 , wherein the hub server 
comprises a database of code for executing instructions to process a communication 

25 containing electronic commerce transaction data, and the communication includes a 
processing instruction reference identifying such code. 

12. The electronic commerce architecture of claim 1, wherein hub server code for 
executing instructions to process a communication containing electronic commerce 
transaction data accepts a parameter identifying a trading partner. 

30 13. An electronic commerce method for producing a signal embodied in a 

distributed computing system, the method comprising: 

including in the signal electronic commerce transaction data in a self- 
documenting format; 
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including in the signal a transaction type which identifies the type of 
commercial transaction to which the electronic commerce transaction data pertains; 

including in the signal routing information for routing the signal to at least one 
of a client and a hub server; and 
5 including in the signal at least one of: 

a substantially complete history which lists at least one event involving 
the electronic commerce transaction data, the history listing at least an event 
which generated the electronic commerce transaction data; 

electronic commerce transaction data which specifies at least one item 
10 without specifying a vendor for the item because the hub server will select a 

vendor for that item; and 

a processing instruction reference identifying code in a database of 
code at the hub server for executing instructions to process the electronic 
commerce transaction data. 
15 14. The method of claim 1 3 , wherein the method includes in the signal electronic 

commerce transaction data in a self-documenting format which includes extensible markup 
language. 

15. The method of claim 13, wherein the transaction type identifies the 
commercial nature of the electronic commerce transaction data as a purchase order. 
20 1 6. The method of claim 13, wherein the transaction type identifies tire 

commercial nature of the electronic commerce transaction data as an invoice. 

17. The method of claim 13, wherein the transaction type identifies the 
commercial nature of the electronic commerce transaction data as a payment. 

18. The method of claim 13, wherein the transaction type identifies the 
25 commercial nature of the electronic commerce transaction data as a catalog. 

19. The method of claim 13, wherein the routing information also specifies a 
transport mechanism for transporting the electronic commerce transaction data. 

20. The method of claim 13, wherein the routing information also specifies a 
format adapter for converting the format of the electronic commerce transaction data. 

30 21. The method of claim 1 3, wherein the method includes in the signal a 

processing instruction reference to a database of code outside the signal for executing 
instructions to process the electronic commerce transaction data. 
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22. A method for integrating disparate systems into transaction communities to 
facilitate electronic commerce, the disparate systems acting on behalf of distinct client 
entities, a transaction community including a plurality of client entities which the method 
relates to one another during a commercial transaction according to their business roles in the 
transaction, the method comprising the steps of: 

obtaining at a first client purchase order data for an electronic commerce 
transaction, the first client being in communication with a first single-entity- 
transaction-system; 

embedding the purchase order data in a first communication which uses 
extensible markup language to document the purchase order data, the first 
communication also containing at least one of (a) a history of the purchase order data 
which includes an entry indicating that the embedded data is purchase order data and 
that the embedded data was obtained at the first client, (b) a specification of at least 
one item which does not specify a vendor for the item, and (c) a processing instruction 
reference identifying code in a database of code at an electronic commerce hub server 
for executing instructions to process the purchase order; 

sending the first communication from the first client to an electronic 
commerce hub server; 

selecting a vendor for any item which has no vendor specified in the first 
communication; and 

sending a second communication from the hub server to a second client, the 
second client being in communication with a second single-entity-transaction-system, 
the second communication using extensible markup language to document the 
purchase order data. 

23 . The method of claim 22, wherein the obtaining step is preceded by the steps of 
installing the first client and installing the second client, each client is installed at a different 
client entity, and the hub server is maintained by a third entity which is an electronic 
commerce service provider. 

24. The method of claim 23, wherein the method further comprises the step of 
remotely updating at least one of the clients. 

25 . The method of claim 22, wherein the method further comprises the step of 
confirming receipt of at least one of the communications. 

26. The method of claim 22, wherein the method further comprises the steps of: 
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obtaining at the second client invoice data corresponding to at least a portion 
of the purchase order data; 

embedding the invoice data in a third communication which uses extensible 
markup language to document the invoice data; 
5 sending the third communication from the second client to the hub server; and 

sending a fourth communication from the hub server to the first client, the 
fourth communication using extensible markup language to document the invoice 
data. 

27. The method of claim 22, wherein the embedding step comprises converting 
10 the purchase order data from an electronic data interchange format into an extensible markup 

language format. 

28. The method of claim 22, wherein the embedding step comprises reading the 
purchase order data from a database and placing the purchase order data in an extensible 
markup language format. 

15 29. The method of claim 22, wherein at least one of the sending steps comprises 

sending encrypted data. 

30. The method of claim 22, wherein the step of sending a second communication 
from the hub server to a second client is followed by the step of sending to at least one person 
identified in the second communication an email notification that the second communication 

20 has arrived. 

3 1 . The method of claim 22, wherein a procurement accounting step is at least 
started between the step of sending the first communication from the first client to a hub 
server and the step of sending a second communication from the hub server to a second 
client, and the procurement accounting step submits the purchase order data to procurement 

25 accounting software on the hub server. 

32. The method of claim 22, wherein the method comprises proactive transaction 
monitoring to determine whether an expected communication has arrived at the hub server 
and to take an exception-handling step in the event that an expected communication has not 
arrived. 

30 33. The method of claim 22, wherein the method comprises use of a pluggable 

transport adapter. 



44 



WO 01/57613 PCT7US01/03087 

34. A computer-readable storage medium configured with software for performing 
electronic commerce method steps according to any one or more of the methods of claims 1 3 
through 33. 
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